Skip to main content

Rate Limits, Billing, and Token Usage

Outter operates on a usage-based model, so understanding rate limits, billing, and token consumption is essential for managing your integration. This section provides transparency on how the API is consumed, what quotas might apply, and how costs are calculated.

Rate Limits​

To ensure fair use and system stability, Outter imposes rate limits on API calls. The limits might vary based on your subscription plan (e.g., free tier vs. enterprise tier). Rate limiting is enforced at the API gateway level. Common rules could be, for example, 60 requests per minute for certain endpoints, or a combined limit like 1000 requests per day for an API key.

When a rate limit is hit, the API will return HTTP 429 Too Many Requests (as discussed in Error Handling). The response will include a Retry-After header indicating when you can send the next request. Outter may also include headers to help you monitor usage, for example:

  • X-RateLimit-Limit: 60 (the max requests in this window)
  • X-RateLimit-Remaining: 0 (how many calls left – here 0 means you’ve exhausted the limit)
  • X-RateLimit-Reset: 1678901234 (epoch timestamp when the limit resets or number of seconds until reset)

Best practices:

  • Spread out requests rather than bursting them all at once.
  • Use batch APIs to reduce call count where possible.
  • Implement backoff and retry for 429 responses as noted earlier.
  • If you anticipate higher call volumes, contact Outter to increase your limits. Outter’s team can often raise limits for trusted production applications or suggest architectural changes to help (such as using webhooks instead of rapid polling).